---
title: Odpravljanje težav
description: Ta razdelek opisuje, kako odpraviti težave z Ultracite.
---

Čeprav Ultracite poskuša poenostaviti lintanje/formatiranje, se lahko med nastavitevjo ali uporabo pojavijo težave ali vprašanja. Tukaj je nekaj pogostih težav in njihovih rešitev:

## “Ultracite isn’t formatting on save in VS Code.”

Preverite, ali imate nameščen in omogočen Biome VS Code extension. Preverite, da vaša `.vscode/settings.json` vsebuje vnose `"editor.defaultFormatter": "biomejs.biome"` in `"editor.codeActionsOnSave"`, kot je prikazano v [Namestitev](/setup).

Prav tako se prepričajte, da ni omogočen noben drug formatter ali linter extension, ki bi bil v konfliktu (na primer, če imate še vedno aktivno Prettier extension ali ESLint extension, lahko ti motijo ali prevzamejo prednost).

Morda boste morali onemogočiti vgrajeno Format On Save v VS Code, če drug formatter prevzame datoteko. Z pravilnimi nastavitvami in Biome extensionom bi shranjevanje datoteke, ki jo Ultracite pokriva (js/ts/jsx/tsx/json/css), moralo sprožiti formatiranje. Če se to ne zgodi, poskusite ročno zagnati ukaz “Format Document” in preverite, ali se uporablja Biome ali se pojavi kakšna napaka.

## “I installed Ultracite, but VS Code still uses ESLint or Prettier.”

Poskrbite, da ste odstranili ali izklopili stare konfiguracije. Na primer, če imate v projektu `.eslintrc` ali `.prettierrc`, je možno, da je VS Code’s ESLint extension še vedno aktiven in povzroča podvojene diagnostike.

Priporočljivo je odstraniti te konfiguracije (ali vsaj onemogočiti ustrezne extensione) pri prehodu na Ultracite, da se izognete zmedi. V bistvu dovolite, da Ultracite/Biome prevzame vlogo edinega linterja/formatterja.

Če iz kakšnega razloga želite obdržati ESLint, ne omogočite “fix on save” za ESLint – sicer bosta obe orodji poskušali popraviti kodo (čeprav, če sta pravilno konfigurirana, bi moral Biome sovpadati s Prettier stilom, da se izognete konfliktom).

Na splošno, popolna migracija na Ultracite pomeni, da konfiguracij ESLint/Prettier običajno več ne potrebujete.

## “Ultracite (Biome) is throwing parse errors for files I don’t want it to check.”

Dober primer je nameščanje komponent iz UI knjižnice, kot je [`shadcn/ui`](https://ui.shadcn.com/). Čeprav so namenjene spreminjanju, boste morda želeli ohraniti izvorno kodo za posodobitve. V tem primeru boste želeli onemogočiti lintanje za te datoteke.

To naredite tako, da v `biome.jsonc` dodate vzorce za izključitev teh datotek, npr.

```json title="biome.jsonc"
{
  "files": {
    "includes": [
      "**/*",
      "!components/ui",
      "!lib",
      "!hooks",
    ]
  },
}
```

Privzeto Biome ignorira `node_modules`, vendar če ste datoteko odprli ročno od tam, lahko extension vseeno poskuša lintati. Na splošno ignorirajte velike generirane datoteke ali kodo tretjih oseb – ni potrebe, da jih lintate.

Drug vzrok je lahko, če v datoteki uporabljate eksperimentalno sintakso, ki je Biome ne more parsirati (npr. stage-3 predlog, ki še ni v Biome). V takem primeru bodisi izogibajte se tej sintaksi ali preverite, ali je Biome mogoče konfigurirati (včasih z dodajanjem `"parser.allowSomething": true` v konfiguracijo, če je na voljo).

Preverite issue tracker Biome za podporo te sintakse.

## “I see double errors for the same issue.”

To se lahko zgodi, če imate hkrati zagnanih več linterjev (na primer ESLint in Ultracite). Lahko se zgodi tudi, če TS checker v VS Code in Biome oba poročata o isti TypeScript napaki. Rešitev je, da standardizirate eno orodje na vrsto preverjanja.

Če uporabljate Ultracite, onemogočite druge linterje. Za TypeScript tipne napake bo VS Code-ov vgrajeni TypeScript server to prikazal (npr. rdeče valovite črte za tipne napake) – Biome lahko prav tako pokaže na tipno pogojene lint napake. Običajno je to v redu, saj izpostavljata isti problem. Če vas to moti, lahko izklopite VS Code-ov TS validator (`"typescript.validate.enable": false` v nastavitvah) in se zanašate na Biome, ali obratno.

V večini nastavitev je puščanje obeh vključenih v redu; običajno se dopolnjujeta (tipne napake proti lint napakam). Le poskrbite, da nimate dveh linterjev z prekrivajočo funkcionalnostjo omogočenih (kot na primer ESLint in Biome, ki oba izvajata lintanje).

## “Pre-commit hook/CI is failing due to Ultracite.”

Če vaš pre-commit hook zažene `ultracite` in spodleti, to pomeni, da so še vedno napake, ki jih ni bilo mogoče avtomatsko popraviti (ali pa je nekdo zaobšel zagon). Najboljši način, da to popravite, je zagnati `npx ultracite` lokalno in pregledati izhod. Ali bo to popravilo stvari (v tem primeru samo dodajte spremembe v stage in ponovno commitajte) ali pa bo poročalo o napakah, ki zahtevajo ročno popravljanje.

Odpravite te napake in nato commitajte. Če CI spodleti pri `ultracite --check`, naredite enako: zaženite ga lokalno z `--check`, da vidite, katere težave je našel, ali pa ga zaženite brez `--check`, da se samodejno popravi in nato commitajte rezultate. Na kratko, obravnavajte neuspehe Ultracite kot neuspešne teste – nekaj, kar je treba popraviti v kodi.

## “I get an error about `strictNullChecks` or type issues after enabling Ultracite.”

Ultracite pričakuje TypeScript strogo nastavitev. Če niste omogočili `strictNullChecks` (ali celotne `strict`), se lahko pojavijo številna TypeScript-povezana lint opozorila (na primer opozorila o potencialni uporabi undefined, ki jih TS ne ujame zaradi bolj sprostih nastavitev).

Rešitev je omogočiti te stroge zastavice v `tsconfig`, kot priporočeno. Če iz kakšnega razloga ne morete (zaradi legacy kode), boste morda morali onemogočiti določena pravila v Ultracite, ki predvidevajo strogo nastavitev. Vendar močno priporočamo, da naredite prehod na TS strict mode – izboljšalo bo kakovost kode in je v skladu s filozofijo Ultracite.

## “Ultracite is too strict for our team (too many rules) – can I tone it down?”

Da. Čeprav je vrednost Ultracite v tem, da je stroga, lahko pravila prilagodite. Če razvijalce preplavljajo opozorila, identificirajte, katera pravila povzročajo trenja. Morda gre za stilistično preferenco ali nekaj, kar ne ustreza vašemu kontekstu. Ta pravila lahko nastavite na `warn` ali `off` v konfiguraciji.

Na primer, če so accessibility pravila preglasna za interni projekt, boste morda nekaj izmed njih onemogočili. Ali pa če se ne strinjate s stilom kode, ki ga izvaja, ga lahko prilagodite (čeprav so stilna nesoglasja to, kar Ultracite poskuša odpraviti).

Ključ je komunikacija s timom – morda razložite, zakaj določeno pravilo obstaja, preden ga onemogočite; če je še vedno nezaželeno, prilagodite konfiguracijo. Ultracite ni črna skrinjica – imate popoln nadzor preko `biome.jsonc`.

Preverite [konfiguracija](/configuration) za več informacij o tem, kako preglasiti pravila.

## “Are there known limitations or bugs with Ultracite I should be aware of?”

Ultracite (natančneje Biome) ne pokriva vsega, kar pokriva kombinacija ESLint + Prettier + Stylelint, še posebej, če uporabljate določene plugine. Na primer, Stylelint je imel obsežen nabor pravil za CSS; Biome trenutno nudi formatiranje za CSS in osnovni lint, vendar ne celotni nabor pravil Stylelint.

Če se vaš projekt zanaša na specifične Stylelint preverjave (kot so razporeditev lastnosti ali specifično poimenovanje v CSS), upoštevajte, da Ultracite teh ne uveljavlja. Po potrebi lahko vključite Stylelint ločeno ali pa počakate, saj Biome morda v prihodnosti doda več CSS lintanja.

---

Če naletite na težavo, ki ni zajeta tukaj, razmislite o preverjanju Ultracite-ove strani z issues na GitHub ali dokumentacije Biome. Morda obstaja popravek ali zaobidetje. Skupnost raste, zato se podpora skozi čas izboljšuje.